Event sourcing

Martin Fowler describes event sourcing as

Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.

Which means in an Event Sourced system we do not store the current state, but a chronologically ordered list of events is persisted. This event sequence can be used to reconstruct the current state into memory, or project it in any other form for presentation or storage. The definition of event in the context of event sourcing refers to a 'state change', rather than a notification as in Event Driven Architecture.

Advantages of event sourcing are:

The main goal is to be able to understand what happens to a business entity over time. But there are a set of interesting things that can be done:

• We can rebuild the data view within a microservice after it crashes, by reloading the event log.
• As events are ordered with time, we can apply complex event processing with temporal queries, time window operations, and looking at non-event.
• Be able to reverse the state and correct data with new events.

Fowler describes the following problems around Event Sourcing:

Event sourcing does have its problems. Replaying events becomes problematic when results depend on interactions with outside systems. We have to figure out how to deal with changes in the schema of events over time. Many people find the event processing adds a lot of complexity to an application (although I do wonder if that's more due to poor separation between components that derive a working copy and components that do the domain processing).

source: IBM Cloud architecture. What do you mean by “Event-Driven”? by Martin Fowler.

Interesting resources

Domain Events vs. Event Sourcing – INNOQ